In a product manufacturing testing environment, tests are developed to determine the acceptability of manufactured products and to learn of sources of manufacturing problems. In a typical integrated circuit assembly manufacturing environment, after manufacture each assembly is submitted to an automated tester to perform such tests as continuity and functionality tests on the assemblies. For example, in-circuit testers may be used to achieve both continuity and functional testing.
Typically, during the manufacture of a given product, there will be several lines of production, calling for multiple identical testers testing products of identical design. Currently, each tester operates autonomously. In this regard, each tester requires a test plan, configuration of its test resources, tests, knowledge concerning the assembly under test, etc. This may require multiple test engineers to set up and monitor the testing during production.
The current operating environment therefore leads to several problems. For example, if a problem occurs during testing on one line, the test engineer must determine the source of the problem. The source of the problem may be a manufacturing defect in the assembly itself, or may be occurring within the tester. Often, however, the source of a test problem comes from the test itself—it may be due to programming errors or improper test limits. Furthermore, depending on the source of the problem, the problem may not be immediately apparent during test development. For example, test threshold limits for various components on the assembly under test may be set at certain levels and appear to test correctly for defects in these components when the test run begins. However, over time, as the temperature of the equipment increases, the limits may become insufficient for certain components whose measurements are temperature dependent, causing false test failures in some components of assemblies that are actually in fact without defect.
The use of multiple autonomous testers in the manufacturing testing environment can lead to several inefficiencies and other problems. The use of multiple testers during the production run of a single assembly design requires a common test plan comprising a suite of tests to be executed on each tester. The test software for each tester is identical by design, but each tester must be configured with an independent copy of the software. This can lead to version control and software update problems between the testers.
Additionally, during test development and production runs, debug knowledge about the test plan, individual tests in the suite of tests that make up the test plan, test limits, and specification information about the individual testers may be collected over time. Information learned on one tester may be helpful to diagnosing problems on other testers. Furthermore, information learned during the production and testing of one assembly may be helpful in the diagnosis of problems encountered during the production and testing of a different assembly. However, because the testers are autonomous and are often operated by different individuals, the overall debugging knowledge is typically distributed and fragmented. Accordingly, it would be useful to develop a technique for accumulating and centralizing the debugging knowledge over time. Furthermore it would be useful to allow common access by all testers and test engineers to this centralized information. In addition, debug information used in the testing of the assembly during production may be helpful to product support engineers for debugging problems with the assembly once they are at a customer site. Accordingly, it would also be useful to allow access to this body of centralized debug knowledge to product support engineers and maybe even portions of this information to certain customers. At the same time, because a manufacturer may not want all debugging knowledge exposed beyond the manufacturing environment, it would be desirable to have a technique for controlling the content and access privileges of the debug knowledge.
Another common problem in debugging a test problem is the lack of a standardized debug plan. Typically, when a test problem is first encountered, the test engineer will sort through the available information regarding the tester configuration, the test being executed, the tester resources configuration, test limits, etc., and the steps performed in debugging the problem are entirely at the discretion of, and dependent upon the experience of, the test engineer. The time required in the diagnosis of any given problem can therefore range significantly in time and number of resources. It would therefore be desirable to have at the very least a debug knowledge base to which all test engineers have access. It would further be desirable to develop from this debug knowledge base a common debug plan that dictates steps to be taken to pinpoint the source of test problems. This would ensure that troubleshooting of problems starts from a known status, ensure that relevant information is being utilized in the diagnosing of the problem, and reduce the amount of time in finding the source of the problem.
It would therefore be desirable to have a product framework for the manufacturing test environment that achieves these objectives.